SSM Patch Manager と Inspector v2 の違いを確認してみた
はじめに
こんにちは！体内の 6 割は水分ではなく、えびだと思うくらいえび好きな kaz です。
突然ですが SSM Patch Manager と、Inspector v2（以下、Inspector） の違いってわかりますか？
大まかには、以下のイメージだと思います。
- SSM Patch Manager
- 定期的にスキャン / セキュリティパッチ適用
- Inspector
- リアルタイム性のあるスキャン
どちらのサービスも用途が異なっているので AWS サービスとしても独立しているはずなんですが・・・。
SSM Patch Manager でも脆弱性スキャンのみを定期的に実施することができるときました。
こうなると、「Inspector との違いがわからなくなってきた・・・。コンプライアンスレポートも出力できるし SSM Patch Manager だけで良くない？」と思うようになり、改めて調査してみました。
結論
まずは、結論から。
「どちらかのサービスだけを使えばいい」というわけではなく、併用することで脆弱性の脅威に対して効率よく対応することが可能となります。
まとめると、SSM Patch Manager と Inspector を併用して、「監視運用そのものが脆弱性対応に追われて破綻」しないようなベースを構築することが目的です。
簡単に言うと、以下のようなイメージです。
- SSM Patch Manager
- 週次や、月次などのタイミングで定めたベースラインに基づいて脆弱性を日頃から対処
- Inspector
- リアルタイム性を重視して、緊急度の高い脆弱性を検出 / 即時対処
引用元: Amazon Inspector と AWS Systems Manager を活⽤した マルチアカウントでの脆弱性管理とパッチの⾃動化
それでは、それぞれのサービスの詳細を確認してみましょう。
※なお、本エントリーでは EC2 インスタンス（OS: Amazon Linux 2）の脆弱性診断をベースとしております
SSM Patch Manager
AWS ドキュメントでは、SSM Patch Manager は以下のように説明されています。
Q: AWS Systems Manager のパッチマネージャーとは何ですか?
AWS Systems Manager により、選択したオペレーティングシステムとソフトウェアのパッチを、Amazon EC2 またはオンプレミスの大規模なインスタンスグループに自動的にデプロイできます。 パッチベースラインによって、オペレーティングシステムパッチや重要度の高いパッチなど、インストールする特定のパッチのカテゴリを自動承認するためのルールを設定できます。 また、これらのルールよりも優先され、自動的に承認または拒否されるパッチのリストを指定できます。 さらに、パッチのメンテナンスウィンドウをスケジュールして、事前に設定した時間にのみ適用されるようにできます。 Systems Manager を使用すると、ソフトウェアが常に最新状態となり、コンプライアンスポリシーを満たすことができます。
https://aws.amazon.com/jp/systems-manager/faq/#Patch_Manager
SSM Patch Manager 特徴
- 前提条件
- SSM Agent の実行 および、SSM マネージドノードであること
- スキャンタイミング
- 定期的（CRON 式や、日単位などのスキャンスケジュールのタイミングを待つ必要がある）
- 手動によるスキャンオペレーションも可能
- パッチ適用
- 定めたベースラインに基づいて、スキャン & 自動パッチ適用が可能（スキャンのみも可能）
- マネージドノードへのパッチ適用は、一括、リソースグループ、タグ付けの可否などによって柔軟に選択が可能
- パッチ適用は、重要度（
Criticalや、Important）に合わせて指定が可能 - 特定のパッチを適用しないように「適用の拒否（拒否済みのパッチリスト）」を指定可能
- セキュリティパッチの更新以外にも
Bugfixなどのセキュリティに関連しないパッチ適用も可能
- 脆弱性の指標 / 評価基準
- パッケージ管理ツールの更新プログラム（
updateinfo.xmlなど）によって評価される
- パッケージ管理ツールの更新プログラム（
- レポート
- CSV 形式でコンプライアンスレポートをエクスポートできる
- コンプライアンス状況の確認
- マネージドノードのパッチ状況によって「準拠 / 非準拠」であるか、コンプライアンス違反の状況をコンソールや、レポートから確認可能
このような特徴があります。
なお、パッチ適用の承認期間を設けることもできるので本番環境にパッチ適用される前に、まずは開発環境などで事前に影響範囲を確認できます。
月次などの定期的なタイミングで、「自動的にパッチを適用する」ことを前提に運用する際に、非常に便利なサービスであることがわかりますね。
ちなみに、Amazon Linux 2 の場合は amzn2-core や、amzn2extra-docker がデフォルトリポジトリとなるため、脆弱性の指標は ALAS (Amazon Linux Security Center) に掲載されています。
Inspector
AWS ドキュメントでは、Inspector は、以下のように説明されています。
Q: Amazon Inspector とは何ですか?
Amazon Inspector は、自動化された脆弱性管理サービスであり、Amazon Elastic Compute Cloud (EC2)、AWS Lambda 関数とコンテナのワークロードを継続的にスキャンして、ソフトウェアの脆弱性と意図しないネットワークのエクスポージャーを検出します。
https://aws.amazon.com/jp/inspector/faqs/?nc=sn&loc=6
Inspector 特徴
- 前提条件
- SSM Agent の実行 および、SSM マネージドノードであること
- スキャンタイミング
- リアルタイム性に優れる（インスタンスの起動時や、パッケージインストールなど検知のタイミングが早い）
- 監視対象サーバーの増減による、追跡が容易（動的な環境に適用）
- リアルタイム性に優れる（インスタンスの起動時や、パッケージインストールなど検知のタイミングが早い）
- パッチ適用
- ソフトウェアの脆弱性スキャンのみであり、パッチ適用は不可能
- 脆弱性の指標 / 評価基準
- ALAS - Amazon Linux 2
- セキュリティアドバイザリのスコアとは別に、独自で Inspector リスクスコアを示す（環境差異によってスコアレベルが増減することがある）
- たとえば、インターネットに晒されていない環境ではスコアが低下する可能性も考えられる
- レポート
- CSV または、JSON 形式で調査結果レポートをエクスポートできる
- その他 / 特徴
- 脆弱性情報を詳しく確認（情報のドリルダウンや、脆弱性対処のヘルプ、環境ごとのスコア算出/優先順位付けなど）
- ECR や Lambda 関数 および、Lambda Layers の脆弱性スキャンにも対応
- 意図していないネットワークの露出を検出（ポートの穴など）
- Deep Inspection を使用して、サポートされるプログラミング言語のパッケージを脆弱性検出可能
Inspector には、これらの特徴がありました。
やはり、ニアリアルタイムにスキャンされることが大きな特徴ではないでしょうか。
また、SSM Agent と、SSM マネージドノードの条件が整っていれば自動的に Inspector のスキャン対象となるのは便利ですね。
他にも、脆弱性に対して詳細な情報を確認することができるので、どのようなコマンドを実行すればその脆弱性に対処できるのかがすぐにわかります。
まとめ
Inspector と SSM Patch Manager ではパッチ適用の可否もそうですが、そもそものアプローチが異なっていることがわかりました。
これらのサービスを利用すれば、完全な自動化は難しいもののパッチ適用における運用周りを強力にサポートしてくれます。
日々の脆弱性によって対応に追われてしまう状況を避けるためにも、ぜひ導入を検討されてみてはいかがでしょうか。
この記事が少しでも誰かのお役にたてば幸いです。
【おまけ】 SSM Patch Manager のパッチスキャン時の動作を確認してみた
Amazon Linux 2 を対象に、SSM Patch Manager のスキャンの仕組み（何を見ているのか）を確認したときのメモです。
Amazon Linux、Amazon Linux 2、Amazon Linux 2022 および Amazon Linux 2023 でのパッチベースラインルールの仕組み
上記のドキュメントを確認してみると、パッケージ管理ツールである yum にて設定された updateinfo.xml ファイルを用いて、スキャンされているようですね。
ちなみに updateinfo.xml ファイルには、パッケージ毎のアップデート情報がずらっーと記載されています。
なお、ファイルは /var/cache/yum/x86_64/2/amzn2-core/updateinfo.xml.gz にキャッシュされていました。
インスタンスのセキュリティアップデート情報を確認してみる
それでは、インスタンスへアクセスしてセキュリティアップデートの情報を確認してみます。
$ yum updateinfo コマンドを実行してみると、重要度 14 個のセキュリティアップデートがあることがわかりました。
$ yum updateinfo
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core/2/x86_64 | 3.7 kB 00:00:00
Updates Information Summary: updates
14 Security notice(s)
1 important Security notice(s)
1 low Security notice(s)
12 medium Security notice(s)
updateinfo summary done
次に、セキュリティアップデートを詳細に見てみると、ALAS の識別子がリストされていることがわかりますね。
$ yum updateinfo list --security Loaded plugins: extras_suggestions, langpacks, priorities, update-motd ALAS2-2023-2070 medium/Sec. curl-8.0.1-1.amzn2.0.1.x86_64 ALAS2-2023-2058 medium/Sec. glib2-2.56.1-9.amzn2.0.5.x86_64 ALAS2-2023-2107 medium/Sec. glib2-2.56.1-9.amzn2.0.6.x86_64 ALAS2KERNEL-5.10-2023-033 important/Sec. kernel-5.10.179-168.710.amzn2.x86_64 ALAS2-2023-2070 medium/Sec. libcurl-8.0.1-1.amzn2.0.1.x86_64 ALAS2-2023-2079 medium/Sec. libfastjson-0.99.4-3.amzn2.0.1.x86_64 ALAS2-2023-2055 low/Sec. libtiff-4.0.3-35.amzn2.0.6.x86_64 ALAS2-2023-2057 medium/Sec. mariadb-libs-1:5.5.68-1.amzn2.0.1.x86_64 ALAS2-2023-2056 medium/Sec. microcode_ctl-2:2.1-47.amzn2.0.15.x86_64 ALAS2-2023-2095 medium/Sec. openldap-2.4.44-25.amzn2.0.6.x86_64 ALAS2-2023-2073 medium/Sec. openssl-1:1.0.2k-24.amzn2.0.7.x86_64 ALAS2-2023-2073 medium/Sec. openssl-libs-1:1.0.2k-24.amzn2.0.7.x86_64 ALAS2-2023-2082 medium/Sec. pcre-8.32-17.amzn2.0.3.x86_64 ALAS2-2023-2074 medium/Sec. rsync-3.1.2-11.amzn2.0.2.x86_64 ALAS2-2023-2064 medium/Sec. tar-2:1.26-35.amzn2.0.2.x86_64 ALAS2-2023-2101 medium/Sec. yajl-2.0.4-4.amzn2.0.2.x86_64
なお、important/Sec のカーネル更新については、SSM Patch Manager でスキャンした際に「非準拠（コンプライアンス違反）」の項目として表示されていました。
このように、パッケージ管理ツールのセキュリティアップデート情報に基づいて SSM Patch Manager のダッシュボードにスキャン結果として表示されていることがわかりました！
アノテーション株式会社について
アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。
「らしく働く、らしく生きる」のスローガンを掲げ、さまざまな背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。
現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。
少しでもご興味あれば、アノテーション株式会社WEBサイト をご覧ください。
